A “bus” is a collection of signals interconnecting two or more electrical devices that permits one device to transmit information to one or more other devices. There are many different types of buses used in computers and computer-related products. Examples include the Peripheral Component Interconnect (“PCI”) bus, the Industry Standard Architecture (“ISA”) bus and the Universal Serial Bus (“USB”), to name a few. Bus operation is usually defined by a standard that specifies various concerns such as the electrical characteristics of the bus, how data is to be transmitted over the bus, how requests for data are acknowledged, and the like. Using a bus to perform an activity, such as transmitting data, requesting data, etc., is generally called running a “cycle.” Standardizing a bus protocol helps to ensure effective communication between devices connected to the bus, even if such devices are made by different manufacturers. Any company wishing to make and sell a device to be used on a particular bus, provides that device with an interface unique to the bus to which the device will connect. Designing a device to particular bus standard ensures that
Thus, for example, an internal fax/modem (i.e., internal to a personal computer) designed for operation on a PCI bus will be able to transmit and receive data to and from other devices on the PCI bus, even if each device on the PCI bus is made by a different manufacturer.
According to most bus protocols, a device that needs to run a cycle on the bus must first gain control of the bus. Once the sending device has control of the bus, that device then can run its desired cycle, which may entail transmitting data to a receiving bus device. Often, more than one bus device may concurrently need to initiate a cycle on the bus. Bus protocols in which multiple devices may request control of the bus to run cycles usually implement some form of arbitration to efficiently decide which device to grant control of the bus among multiple devices requesting control. The prior art is replete with many types of arbitration schemes.
Currently, there is a market push to incorporate various types of consumer electronic equipment with a bus interface that permits such equipment to be connected to other equipment with a corresponding bus interface. For example, digital cameras, digital video recorders, digital video disks (“DVDs”), printers are becoming available with an IEEE 1394 bus interface. The IEEE (“Institute of Electrical and Electronics Engineers”) 1394 serial interface (and all its variations, referred to collectively herein as “1394” unless otherwise noted) describes a bus that permits a digital camera to be connected to a printer or computer so that an image acquired by the camera can be printed on the printer or stored electronically in the computer. Further, digital televisions can be coupled to a computer or computer network via an IEEE 1394 standard-compliant bus.
Current solutions for encoding IEEE 1394 standard-compliant data, arbitration states and control states onto 10-bit symbols for use in IEEE 1394c standard-compliant (aka T_mode) data transmission are not robust to byte errors which may occur when IEEE 802.3 Clause 40-compliant PRY encoding is used to transport 1394 protocols. In particular, a single byte error in the 802.3 Clause 40 encoding may result in two errored 10-bit symbols at the 1394 level. This is particularly of concern should the two symbols be a pair of 1394 control symbols, such as used to separate data from arbitration requests.
The IEEE 1394b standard alternates arbitration request signaling and packet transmission. Packet transmission commences with the transmission of specific control symbols indicating packet prefix, and terminates with further specific control symbols. All symbols are encoded as 10-bit values. Data symbols and control symbols in accordance with the 1394b format are as follows. ARB is a data symbol representing an arbitration request, SP is a SPEED control symbol which introduces a packet and indicates its speed, DP is a DATA_PREFIX control symbol which introduces a packet, D is a data symbol representing packet payload, and DE is a DATA_END control symbol which terminates a packet. For robustness against single bit errors, control symbols are typically sent twice, or at least a packet is introduced by a pair of control symbols, both of which set the “in packet” context.
In 1394b Beta mode, all symbols are encoded as 10-bit symbols using an extension of the IBM 8B10B code definition. Both arbitration signals and data signals use 8B10B data values. 1394b encoding requires that the “in-packet” context be maintained in order to distinguish between a data symbol used as packet payload and a data symbol used as an arbitration request symbol. The “in-packet” context is set by the SPEED and DATA_PREFIX control symbols, and reset by control symbols such as DATA_END, GRANT, ARB_CONTEXT, all of which terminate a packet. DATA_PREFIX may also be used to separate packets—terminating one packet and immediately introducing a second packet.
In 1394b Beta mode, signaling uses NRZ encoding, which is electrically specified to have a bit error rate of less than 1 error in 1012 bits. The (extended) 8B10B encoding will always detect a single-bit error in a control symbol, and will detect a single-bit error in a data symbol either immediately or shortly afterwards due to a running disparity failure. If a bit error occurs in an arbitration symbol, this is relatively harmless as the error will be corrected in the succeeding arbitration symbol. The 1394b arbitration mechanisms are also robust against dropped or erroneous arbitration symbols—in general the result will be no worse that “unfairness” or a dropped isochronous packet, and usually totally benign. If a bit error occurs in the packet data payload, then this will be caught by packet checksums, and a retry made (where appropriate).
In an embodiment, the format of the present invention uses double instances of control symbols at all times, in particular at the start and end of packets, to provide a measure of robustness against a bit error occurring within a control symbol. The chance of two errors occurring in two consecutive control symbols in an otherwise relatively reliable connection is considered remote.
In order to preserve and reuse the functionality and timing properties of the 1394b arbitration protocols, 1394c requires a one-to-one correspondence between 1394b 10-bit symbols transmitted/received at S800 and 1394c symbols, both in functionality and in duration. Thus each 1394c symbol must have a 10-bit representation at a nominal transmission rate of 983.04 Mbit/sec. However, the 1394c representation of the symbols can be different from that of 1394b. It was recognized that 1394b scrambling provides no advantage, nor does the robustness to single-bit errors provided by 8B10B encoding, when using IEEE 802.3 Clause 40 signaling. Both of these are due to the properties of the lower level transmission specified the IEEE 802.3 Clause 40 signaling. Thus, 1394c simplifies the 1394b encoding by deleting the use of scrambling and 8B10B encoding. This preserves functionality and timing.
In 1394c T_mode, the symbols are currently encoded as follows. Two type bits are followed by eight symbol bits. Arbitration requests and control symbols are encoded identically to 1394b before 8B10B encoding. The two type bits indicate a data value if both type bits are set to zero; an arbitration request if the first type bit is set to zero and the second type bit is set to one; and a control symbol if the first type bit is set to one and the second type bit is set to zero. However, this encoding lacks robustness, particularly to the anticipated failure modes of the 802 Clause 40 signaling. A transmission failure when using 802.3 Clause 40 signaling results typically in a single byte error or in a burst of consecutive byte errors. Thus an encoding which provides robustness only to single bit errors is considered inadequate. However, the 802.3 Clause 40 signaling layer detects and reports such byte errors, so it is not necessary to implement an additional error detection mechanism.
The resulting 10-bit symbol stream is then transmitted as a stream of 802.3 Clause 40 standard-compliant 8-bit bytes, on a “five-to-four” basis—i.e. five 8-bit bytes transmitted for every four 10-bit 1394c symbols, as illustrated in FIG. 1. However, the electrical signaling used for transmission of 802.3 Clause 40 standard-compliant bytes may result in an errored byte. In an errored byte, all eight bits are unreliable. The immediate problem that this causes is that a single 802.3 Clause 40 error will result, in some cases, in two consecutive 1394c standard-compliant symbols being in error.
For example, as shown in FIG. 1, an error in byte a will result in symbol A being errored, and an error in byte e will result in symbol D being errored. But an error in byte b results in both symbols A and B being errored. An error in byte c results in both symbols B and C being errored. An error in byte d results in symbols C and D being errored. Thus there is a 60% chance of a single 802.3 Clause 40 error affecting two consecutive symbols.
Depending on where in the data stream the original error occurs, there is a significant possibility that the two errored 1394c standard-compliant symbols are the two consecutive control symbols that either introduce or terminate a packet. This problem can seriously degrade data transmission. Thus, there is a heartfelt need for a more robust encoding.